1. Field of the Invention
The present invention relates to automation and validation techniques for designing electronic circuits. In particular, the present invention relates to automation and validation techniques for designing electronic circuits that are particularly applicable to system-on-a-chip type electronic circuits.
2. Description of the Related Art
It is conventional to use field programmable gate array (FPGA) devices from vendors such as Xilinx and Altera to prototype application specific integrated circuits implemented as masked gate arrays or standard cells. However the limitation of pins is a barrier to debugging an incorrect design. Individual FPGAs may have their observability enhanced by embedding Logic Analyzer intellectual property but at a cost of routing and logic resources which negatively impacts the amount of user logic that can easily be placed and routed automatically. A single FPGA being debugged may be attached to a host computer for control and display. It is awkward for two FPGAs to work together and be attached to separate host computers.
It is known that Field Programmable Gate Arrays (FPGA) are used for prototyping large electronic circuits and that tools and methodologies exist for debugging the signals on any one FPGA. These tools require substantial routing and logic resources of each FPGA which are not available for the prototype.
A problem exists where debugging a complex electronic circuit requires a plurality of FPGA. While it is possible to emulate each FPGA of a prototype which requires multiple FPGAs, it is extremely difficult to understand problems which cross the boundaries of one FPGA to another FPGA. It is known that the single chip FPGA debugging solution does not scale.
A first generation system controls an FPGA compiler to deliver signals which are to be observed, to the external pins. But input and output pins are frequently the bounding resource in FPGAs and functional blocks may not fit at all into an FPGA with reduced pins.
A second generation system embeds a simple internal logic analyzer to trigger off a simple logic equation and deliver on a small sequence of events. Multiple instances of this internal logic analyzer were required to be useful and functionality was thinner than desired.
A third generation system combines a plurality of FPGAs but only allows one of the FPGAs to be probed. This could only debug problems that luckily originated in one part of the design. It was unable to deal with problems that spanned the FPGA partitioning.
More recently, four high performance transceiver types have been introduced to address distinct requirements: GTP (6.6 Gb/s) in Artix-7 FPGAs provide mainstream low power connectivity in ultra low-cost packages; GTX (12.5 Gb/s) in Kintex-7 and Virtex-7 FPGAs provide cost effective 12.5 Gb/s optical and backplane applications; GTH (13.1 Gb/s) in Virtex-7 FPGAs support 25% overhead required for EFEC in wired OTU and high performance backplane applications with low power; and GTZ (28.05 Gb/s) in Virtex-7 HT FPGAs enable bandwidth for 100-400 G applications supporting major high-speed serial and optical protocols. As is known, Artix, Kintex, and Virtex are trademarks owned by their respective owners. They are provided as non-limiting exemplary gigabit transceivers commercially available. Within this patent applications gigabit transceivers refer to any of the above or their equivalents without limitation.
A conventional FPGA debugging tool is restricted to the signals within a single FPGA and consumes resources which reduce the amount of user logic that may be implemented within the single FPGA. This makes place and route of the user logic more difficult because both pin, logic elements, and channels are consumed by the debugging circuit.
Here are the conventional steps in the design flow:    1. Conventional: Set up user design    1a. Perform initial design entry    1b. Perform synthesis and place-and-route    1c. Program the single device and test    2. Conventional: Set up conventional embedded logic analyzer    2a. Create file of signals desired for observability    2b. Select signals for analysis    2c. Setup signals, triggers, conditional triggers, hierarchical triggers    3. Conventional: Capturing, Displaying, and Analyzing Sample Signal Values    3a. Re-program the single device and test    3b. Displaying the sampled signal values on attached host computer    3c. Analyzing data to identify problems in the user design.
Thus it can be appreciated that what is needed is a way to debug a “system on a chip” which includes software executing on embedded processors. In particular, the problem being solved is to trigger logic value capture as a result of a combination of signal sequences internally used among a plurality of FPGAs.